Can we not extend existing sqs instrumentation? We shouldn't be publishing two instrumentation packages for the same library. This will cause a lot of confusion. We'll be putting additional burden on users to figure out which one to use. What happens if both instrumentations are installed? Will both work? Will one cancel the other? Will the cancellation be deterministic? Even if the answer is a No today, further chances to one lib could end up breaking the other.

Personally if we think this implementation is far superior and it'd be harder to add these features to existing one, I'd rather completely replace the existing one with this instead of creating a new competing package.

I see this is for boto3 while as the old one is for boto. Makes sense.

I'll review the code in more detail shortly but at first glance, any reason we don't follow same pattern as boto instrumentation where we have a single boto/botocore package with extensions for things like sqs and s3?

I'll review the code in more detail shortly but at first glance, any reason we don't follow same pattern as boto instrumentation where we have a single boto/botocore package with extensions for things like sqs and s3?

+1 to this. I personally liked how OTel JS does it where they have a single instrumentation package (they actually have one pkg both v3 and v2, but it's fine that we how one for boto3 spearately) where they have a package for v3 that includes several extensions for the multiple services.

They have a ServiceExtensions.ts file where they register the different services

constructor() {
    this.services.set('SQS', new SqsServiceExtension());
    this.services.set('SNS', new SnsServiceExtension());
    this.services.set('DynamoDB', new DynamodbServiceExtension());
    this.services.set('Lambda', new LambdaServiceExtension());
  }

and their file organization by service looks very clean too.

It would be nice for users to have opentelemetry-instrumentation-boto3 and find immediate tracing for all the services that they do end up using without having to install more packages 🙂. If size were an issue (like it is in Lambda) then we can always mini-fy the code for services we don't use by removing directories.

As another point, what about calling this opentelemetry-instrumentaiton-boto3-sqs since there is no boto3sqs package? I don't know how this will break our scripts that count on that divider 😅

I'll review the code in more detail shortly but at first glance, any reason we don't follow same pattern as boto instrumentation where we have a single boto/botocore package with extensions for things like sqs and s3?

I would really love for it to have been like this. Unfortunatly, as I state in the documentation, the SQS classes are loaded in runtime from a template via the boto3.client function. This means I cannot instrument it until created, and that's why I wrap the boto3.client function.

I'll review the code in more detail shortly but at first glance, any reason we don't follow same pattern as boto instrumentation where we have a single boto/botocore package with extensions for things like sqs and s3?

+1 to this. I personally liked how OTel JS does it where they have a single instrumentation package (they actually have one pkg both v3 and v2, but it's fine that we how one for boto3 spearately) where they have a package for v3 that includes several extensions for the multiple services.

They have a ServiceExtensions.ts file where they register the different services

constructor() {
    this.services.set('SQS', new SqsServiceExtension());
    this.services.set('SNS', new SnsServiceExtension());
    this.services.set('DynamoDB', new DynamodbServiceExtension());
    this.services.set('Lambda', new LambdaServiceExtension());
  }

and their file organization by service looks very clean too.

It would be nice for users to have opentelemetry-instrumentation-boto3 and find immediate tracing for all the services that they do end up using without having to install more packages 🙂. If size were an issue (like it is in Lambda) then we can always mini-fy the code for services we don't use by removing directories.

As another point, what about calling this opentelemetry-instrumentaiton-boto3-sqs since there is no boto3sqs package? I don't know how this will break our scripts that count on that divider 😅

We can create an opentelemetry-instrumentation-boto3 package which will depend on both opentelemetry-instrumentation-botocore and opentelemetry-instrumentation-boto3sqs, and just use their instrumentations. This way users will just install opentelemetry-instrumentation-boto3 but we will be able to keep separation for ease of use. @NathanielRN WDYT?

• Edit: I tried changing to opentelemetry-instrumentaiton-boto3-sqs but it didn't go so well. I wasn't able to import the package afterwards.

It sounds like something is wrong with our packaging system. Ideally it shouldn't matter whether a something is a sub-module or an entirely different package. Could you share more details about the issues you ran into when trying to organize this as a single package?

By single package, I mean opentelemetry-instrumentation-boto3. I don't think we should have a single package for both boto and boto3. They are technically different libraries so we should have different instrumentation packages.